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ShayloY E. Dun 

Description 

METHODS AND SYSTEMS FOR IDENTIFYING, REDIRECTING, AND 
PROCESSING MESSAGES OF DIFFERENT SS7 PROTOCOL 

VARIATIONS 



Technical Field 

The present invention relates to methods and systems for identifying, 
redirecting, and processing messages of different SS7 protocol variations. 
More particularly, the present invention relates to methods and systems for 
1 0 identifying SS7 messages to be redirected to a service control point of one SS7 
protocol variation and for inserting an indicator in the message to identify the 
protocol variation of the SS7 message that allows the service control point to 
process the message. 



15 Background Art 

SS7 is a signaling protocol used internationally to establish and tear 
down calls and to query databases for information relating to calls and 
subscribers. However, different countries use different variations of the SS7 
protocol. For example, in the United States, ANSI SS7 is the dominant 

20 signaling protocol. In Europe, individual countries use ITU-N SS7 for signaling 
in networks within the countries. For signaling between countries, the ITU-I 
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SS7 protocol is used. Each of these SS7 protocol variations include different 
message formats. Within national networks, signaling nodes, such as signal 
transfer points and service control points, are typically configured to recognize 
only one SS7 protocol variation. Gateway nodes are placed between networks 
5 to convert from one SS7 protocol variation to another protocol variation. 
However, these gateway nodes are simply protocol converters. These protocol 
converters do not have the capability to intelligently redirect or process 
messages based on SS7 protocol variation. 

In some instances, it may be desirable to redirect messages to a service 

1 0 control point of a particular SS7 protocol variation. For example, as illustrated 
in Figure 1, an ANSI STP 100 is connected to an ANSI SCP 102 and an ANSI 
SS7 network 104. In one processing scenario, it may be desirable to allow 
calls from ANSI SS7 network 104 to be completed only during certain times of 
day. The times of day that calls are allowed may be stored in ANSI SCP 1 02. 

1 5 Accordingly, when ANSI SS7 network 104 sends an ANSI ISUP message to a 
destination end office, ANSI STP 100 may redirect the ISUP message to ANSI 
SCP 102 to determine whether the call should be allowed. This redirection 
may be accomplished by encapsulating the ANSI ISUP message in an SCCP 
unit data message, which is in turn encapsulated in an MTP message. ANSI 

20 SCP 102 receives the encapsulated message, determines whether the call 
should be completed, and if the call is allowed, forwards the ISUP message to 
its intended destination. 
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Conventional STP redirect functions are capable of redirecting 
messages formatted according to a single SS7 protocol variation. Thus, when 
ANSI STP 100 illustrated in Figure 1 receives an ITU-N message or ITU-I ISUP 
message, the message would be discarded. Discarding messages relating to a 
5 call is undesirable, since the calls would not be completed. Accordingly, there 
exists a need for improved methods and systems for identifying, redirecting, 
and processing messages of different SS7 protocol variations. 



Disclosure of the Invention 

10 The present invention includes methods and systems for identifying, 

redirecting, and processing messages of different SS7 protocol variations. In 
one example, a signaling message routing node receives an ISUP message of 
one SS7 protocol variation. The signaling message routing node determines 
whether the message should be redirected to a service control point. The 

1 5 signaling message routing node also identifies the SS7 protocol variation of the 
ISUP message. The signaling message routing node then encapsulates the 
ISUP message in an SCCP message. The SCCP message is then 
encapsulated in an MTP message. The SCCP and MTP messages may be 
formatted according to a predetermined SS7 protocol variation. 

20 According to one important aspect of the invention, the signaling 

message routing node identifies the protocol variation of the original ISUP 
message and inserts an indicator of that protocol variation in the encapsulating 
SCCP message. This indicator allows the receiving node to properly decode 
and process the encapsulated message, even if the receiving node uses a 
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different protocol variation than the protocol variation of the encapsulated 
message for external communications. For example, if the original ISUP 
message is an ITU-N ISUP message and the message is being sent to an SCP 
that uses ANSI SS7, the ITU-N ISUP message may be encapsulated in an 
5 ANSI SCCP packet and an ANSI MTP-3 packet. However, in the ANSI SCCP 
packet, the signaling message routing node may insert an indicator that 
indicates that the payload is ITU-N. The signaling message routing node may 
then forward the encapsulated ITU-N message to the ANSI SCP. The ANSI 
SCP may then decode the encapsulating SCCP message and identify the 

10 protocol variation of the payload. Since the ANSI SCP knows the protocol 
variation of the payload, the SCP may then decode the payload using the ITU- 
N protocol. The SCP may then determine whether the payload message 
should be forwarded to its destination. 

In an alternate implementation of the invention, rather than redirecting 

15 only ISUP messages, the multi-protocol redirect function of the present 
invention may be used to redirect SCCP messages to SCPs for providing an 
appropriate database service. In performing multi-SS7-variation SCCP 
message redirection, received SCCP messages may be encapsulated in SCCP 
and MTP-3 headers of a predetermined protocol type. The SCCP message 

20 may indicate the protocol variation of the payload. The receiving node may 
decode and process the payload using the protocol variation indicator. 

In yet another implementation of the invention, rather than having a 
single SCP capable of decoding payloads having multiple SS7 protocol 
variations, an STP may be connected to SCPs of different protocol variations 
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and may redirect the message to the SCP of the appropriate protocol 
variations. In this scenario, the protocol indicator would not be required to be 
sent in the message because the message would be formatted according to 
the appropriate SS7 protocol variation and sent to the appropriate SCP. 
5 Accordingly, it is an object of the invention to provide methods and 

systems for identifying, redirecting, and processing messages of different SS7 
protocol variations. 

It is another object of the invention to provide methods and systems for 
processing SS7 messages of different SS7 protocol variations based on 
10 indicator inserted in the SS7 messages. 

Some of the objects of the invention having been stated hereinabove, 
and which are addressed in whole or in part by the present invention, other 
objects will become evident as the description proceeds when taken in 
connection with the accompanying drawings as best described hereinbelow. 

15 

Brief Description of the Drawings 
Preferred embodiments of the invention will now be explained with 
reference to the accompanying drawings of which: 

Figure 1 is a block diagram illustrating message redirection in a 
20 conventional SS7 network that utilizes a single variation of the SS7 protocol; 

Figure 2 is a block diagram illustrating message redirection using a 
signal transfer point capable of identifying and redirecting messages of different 
SS7 protocol variations and a service control point capable of processing SS7 
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messages of different SS7 protocol variations according to an embodiment of 
the present invention; 

Figure 3 is a block diagram illustrating an exemplary internal architecture 
of a signal transfer point capable of identifying and redirecting SS7 messages 
5 of different SS7 protocol variations according to an embodiment of the present 
invention; 

Figure 4 is a block diagram illustrating exemplary processing at an 
inbound link interface module for SS7 messages of different SS7 protocol 
variations according to an embodiment of the present invention; 

10 Figure 5 is block diagram illustrating exemplary processing at an 

outbound link interface module for SS7 messages of different protocol 
variations according to an embodiment of the present invention; and 

Figure 6 illustrates an alternate embodiment of the invention in which an 
STP of the present invention is configured to identify SS7 messages of different 

15 protocol variations and to direct these messages to SCPs of the appropriate 
protocol variation and/or service type. 

Detailed Description of the Invention 
Figure 2 illustrates a network including an STP 200 capable of 
20 identifying and redirecting SS7 messages of different SS7 protocol variations 
and an SCP 202 capable of processing SS7 messages redirected by STP 200. 
In the illustrated example, STP 200 is connected to ANSI SS7 network 204, an 
ITU-I network 206, and an ITU-N network 208. STP 200 is preferably capable 
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of receiving SS7 messages from all three types of networks, identifying the SS7 
protocol variations of the messages, redirecting predetermined SS7 messages 
to SCP 202 and including an indicator in the redirected messages that indicates 
the SS7 protocol variation of each message. STP 200 and SCP 202 
5 communicate using one SS7 protocol variation. In the illustrated example, the 
SS7 protocol variation used for communications between STP 200 and SCP 
202 is assumed to be the ANSI SS7 protocol. However, SCP 202 is also 
capable of decoding encapsulated messages received from STP 200 of 
different SS7 protocol variations using the indicators provided by STP 200. 

1 0 In the illustrated example, ITU-I SS7 network 206 is assumed to send an 

ITU-I ISUP message to STP 200. The ITU-I ISUP message may be addressed 
to the point code of an end office in ITU-N network 208. Because the operators 
of networks 206 and 208 may only allow calls to be completed between their 
networks during certain time periods, STP 200 may redirect the ITU-I message 

15 to SCP 202. Identifying whether the message should be redirected may be 
performed using gateway screening and a redirect table associated with 
gateway screening. The parameters used to identify whether the message 
should be redirected may include the OPC, the DPC, and the service indicator. 
Once STP 200 identifies the message as a candidate for redirection, STP 200 

20 encapsulates the message in an ANSI SCCP packet and encapsulates the 
ANSI SCCP packet in an ANSI MTP-3 packet. It is understood that the SCCP 
and MTP-3 encapsulation may be performed in a single step. STP 200 
preferably also inserts an indicator in the message that communicates to SCP 
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202 that the message payload is ITU-I ISUP. This indicator may be inserted in 
any unused field in the message. In one example, the SS7 protocol variation 
indicator may be inserted in the calling party subsystem number of the 
encapsulating SCCP message. For example, the subsystem number may be 
5 set to "0" for ANSI format or "1" for ITU format. The network indicator 
parameter in the ISUP message may be used to indicate whether an ITU ISUP 
message is of the ITU-N protocol or the ITU-I protocol. 

Upon receiving the message, SCP 202 examines the protocol variation 
indicator and determines the SS7 protocol variation of the payload message. 
1 0 The indicator inserted by STP 200 enables SCP 202 to decode ISUP and other 
message types of different SS7 protocol variations while only being required to 
implement external message routing and SCCP connection control in one of 
the variations. 

The present invention is not limited to using a protocol variation indicator 
15 in a message to indicate the SS7 protocol variation to an SCP. In an alternate 
implementation, ratherthan inserting an indicator in an unused field orfields of 
a redirected message, STP 200 may have different links or linksets connected 
to SCP 202, where each linkset corresponds to a particular protocol variation. 
STP 200 may be configured to redirect ITU-I ISUP messages over one linkset, 
20 ITU-N ISUP messages over another linkset, and ANSI ISUP messages to SCP 
202 over yet another linkset. SCP 202 would then know how to process the 
messages based on the linkset from which the messages were received. In 
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this example, STP 200 preferably still encapsulates the ISUP messages in 
ANSI SCCP and MTP packets. 

Figure 3 illustrates an exemplary internal architecture for STP 200 for 
identifying and redirecting SS7 messages having multiple different SS7 
5 protocol variations. Referring to Figure 3, STP 200 includes a plurality of 
internal processing cards or modules connected by a pair of buses. In the 
illustrated example, these modules include a link interface module 302, a data 
communications module 304, and database services modules (DSMs) 306 and 
308. The modules are connected by a pair of counter-rotating ring buses 310. 

10 Link interface module 302 is configured to send and receive SS7 

messages over SS7 signaling links. Accordingly, link interface module 302 
includes SS7 level 1 and 2 function 312 for performing SS7 level 1 and 2 
functions, such as error detection, error correction, and sequencing. Gateway 
screening function 314 screens messages based on one or more parameters in 

1 5 the messages to determine whether to allow the messages into the network. In 
addition, gateway screening function 314 identifies messages as redirection 
candidates. As discussed above, gateway screening function 314 may use the 
OPC, the DPC, and the service indicator to determine whether a message is a 
candidate for redirection. Multi-SS7-variation ID/redirection function 316 

20 receives messages identified as redirection candidates, encapsulates the 
messages in an SCCP and MTP packets of an SS7 protocol variation, inserts a 
protocol variation indicator in the packets, and forwards the packets to 
discrimination function 318. Discrimination function 318 determines whether 
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received messages should be passed to routing function 320 for routing to an 
appropriate outbound signaling link or to distribution function 318 to be 
distributed internally for further processing. This determination may be made 
based on the destination point code in the message. Routing function 322 
5 routes messages identified as requiring external routing. Distribution function 
320 distributes messages identified as requiring further internal processing by 
STP 200. 

Data communications module 304 includes functions for sending and 
receiving SS7 messages over IP signaling links. In the illustrated example, 

10 these modules include a physical layer function 324 for performing OSI 
physical layer functions, such as modulating data signals onto a carrier for 
transmission over a physical medium. Datalink function 326 performs OSI 
datalink functions, such as ensuring reliable communications between directly 
connected nodes. Network function 328 performs network layer routing, such 

15 as IP routing. Transport function 330 performs transport layer functions, such 
as connection management, reliable end-to-end delivery of messages and flow 
control. SS7 adapter layer 332 includes functions for sending and receiving 
SS7 messages over an underlying IP network. SS7 adapter layer 332 may 
implement M2PA, M3UA, M2UA, SUA, or any other suitable SS7 adapter layer 

20 protocol. Functions 314-322 perform similar functions to the correspondingly 
numbered components described above with regard to LIM 302. 

DSMs 306 and 308 may perform various database services, such as 
global title translation and number portability translation. In the illustrated 
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example, each DSM includes a signaling connection routing controller 334 for 
controlling overall SCCP functions. One SCCP function that may be called or 
initiated by SCRC 334 is global title translation function 336. Global title 
translation function 336 performs intermediate and final global title translations 
5 on received messages indicated as route-on-global title. In order to perform 
these translations, global title translation function 336 accesses GTT tables 
336. After global title translation, messages are passed to routing function 322 
for final routing. Specific examples will be described below where SCCP 
messages are encapsulated in new SCCP packets and sent to DSMs 306 and 

1 0 308 for global title translation of the encapsulating SCCP packet. The purpose 
of global title translating the encapsulating SCCP packet is to send different 
messages to different services or to perform load sharing. In addition, 
message redirection and screening may be performed after global title 
translation, as will be described in detail below. 

15 Figure 5 illustrates exemplary processing at inbound LIM 302 for an 

incoming ITU ISUP message that triggers message redirection. In the 
illustrated example, ISUP message 400 is received by LIM 302. The message 
is from an ITU OPC and addressed to an ITU DPC. Gateway screening 
function 314 identifies the message as requiring redirection service. 

20 Accordingly, gateway screening function 314 forwards the ITU ISUP message 
to multi-SS7-variation ID/redirection function 316. 

Multi-SS7-variation ID/redirection function 316 encapsulates ITU ISUP 
message 400 in the payload portion of an ANSI SCCP message 402. ANSI 
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SCCP message 402 is then encapsulated in an ANSI MTP message 404. 
Multi-SS7-variation ID/redirection function 316 inserts an SS7 protocol variation 
indicator identifying the SS7 protocol variation of the payload of the message in 
the calling party subsystem number field of the encapsulating SCCP message. 
5 In this case, the calling party subsystem number would identify the payload as 
an ITU ISUP message. Accordingly, SCP 202 would know how to decode and 
process the payload when it receives the message. After inserting the protocol 
variation indicator in the message, multi-SS7-variation identifier/redirection 
function 316 forwards the message to discrimination function 318. Since the 

10 encapsulating MTP-3 message is addressed to a DPC associated with SCP 
302, discrimination function 318 forwards the message to routing function 322. 
Routing function 322 then routes the message to the card associated with the 
outbound signaling link. 

Figure 5 is a block diagram illustrating exemplary outbound message 

1 5 processing of the SCCP-encapsulated ISUP message. Referring to Figure 5, 
encapsulated ISUP message 400 is received by outbound DCM 304. M3UA 
and SCTP/IP functions 324-332 encapsulate SCCP-encapsulated ISUP 
message 400 in an SCTP/IP/M3UA message 500. Once functions 324-332 
complete the encapsulation, the message is forwarded to SCP 202 over the 

20 appropriate outbound signaling link. Because the message includes an 
indicator indicating the message type, SCP 202 knows how to decode the 
message. As a result, SCP 202 can implement ANSI as its external SS7 
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protocol variation while being able to decode ISUP messages of other SS7 
protocol variations. 

In an alternate embodiment of the invention, rather than redirecting ISUP 
messages to a single SCP capable of decoding multiple SS7 protocol 
5 variations, multi-SS7-variation identifier/redirection function 316 may configured 
to encapsulate received messages in an SCCP packet of the appropriate 
protocol variation and forward the messages to SCPs of the appropriate 
protocol variation. Figure 6 illustrates a network in which this capability may be 
useful. In Figure 6, STP 200 is connected to ANSI SCP 600, and ITU-I ISUP 
10 STP 602, and ITU-N STP 604. In the examples illustrated in Figure 6, it is 
assumed that each SCP has a separate point code of the corresponding 
protocol variation. Alternatively, or in addition, each SCP may have an IP 
address. 

If an incoming ANSI ISUP message is indicated as a candidate for 
15 redirection, multi-SS7-variation identifier/redirection function 316 may 
encapsulate the ANSI ISUP message in an ANSI SCCP message and forward 
the message to ANSI SCP 600. If an ITU-I ISUP message is received, multi- 
SS7-variation ID/redirection function 316, may encapsulate the message in an 
ITU-I SCCP message and forward the message to ITU-I SCP 602. If an ITU-N 
20 message is received, multi-SS7-variation identifier/redirection function 316 may 
encapsulate the message in an ITU-N message and forward the message to 
ITU-N SCP 604. Thus, by identifying the SS7 protocol variation and redirecting 
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messages to the appropriate SCP, the present invention ensures that 
messages will be decoded properly. 

The present invention is not limited to identifying the protocol variation of 
received ISUP messages and redirecting these messages to the appropriate 
5 SCP. In an alternate embodiment of the invention, multi-SS7-variation 
ID/redirection function 316 may be configured to redirect SCCP messages as 
well as ISUP messages. In performing SCCP message redirection, multi-SS7- 

variation ID/redirection function 316 may encapsulate the messages in an 

j 

SCCP and MTP headers addressed to STP 200. The translation type and the 
10 global title address in the SCCP header may be the same for all SCCP 
message if only one service type is provisioned for redirected messages. 
Alternatively, if multiple service types are provisioned, multi-SS7-variation 
ID/redirection function 316 may map the OPC and DPC in an incoming 
message to appropriate translation type so that the messages requiring 
1 5 different services will be global-title-translated differently and routed to a node 
capable of providing the requisite service. Once SCCP-encapsulated SCCP 
messages are received by a DSM module, the DSM module performs global 
title translation on the encapsulating SCCP header. The result of the global 
title translation is a point code and subsystem number, which may correspond 
20 to one of the SCPs connected to STP 200. Accordingly, the multi-SS7- 
variation identification and redirection functionality of the present invention can 
apply to received SCCP messages, as well as ISUP messages. 
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In addition to performing multi-SS7-variation identification and 
redirection processing on the inbound link interface module, the present 
invention may also include performing such screening on the DSM module after 
global title translation. Performing mu!ti-SS7-variation identification and 
5 verification after global title translation increases the likelihood that messages 
will be properly redirected based on the global-title-translated destination point 
code. 

Although the embodiments described above relate to redirecting 
messages of different SS7 protocol variations to an SCP, the present invention 

1 0 is not limited to redirecting messages to an SCP. Redirecting messages to any 
suitable application, including applications resident on an SCP, is intended to 
be within the scope of the invention. 

Thus, the present invention provides methods and systems for 
identifying, redirecting, and processing messages of multiple different SS7 

15 protocol variations. Identifying the protocol variation of a received message 
and communicating the variation to an SCP allows an SCP that communicates 
externally using one SS7 protocol variation to process messages of multiple 
different SS7 protocol variations. Without the ability to identify the SS7 protocol 
variation of a received message, such an SCP would simply discard messages 

20 of protocol variations other than its native protocol variation. The present 
invention avoids this problem and thus increases the likelihood that calls will be 
competed. 

It will be understood that various details of the invention may be 
changed without departing from the scope of the invention. Furthermore, the 
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foregoing description is for the purpose of illustration only, and not for the 
purpose of limitation, as the invention is defined by the claims as set forth 
hereinafter. 



